This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
HTTP adaptive technologies are pushed by various stakeholders to allow provision of over the top audiovisual delivery in the Internet. Such technologies allow a client device to receive video in the form of small successive segments (a few seconds long), so called chunk. Each segment is requested through the HTTP protocol and may exist in different variants (so called representations), allowing the client device to choose at any time an appropriate bit rate matching the network and device constraints.
Among the HTTP adaptive streaming (HAS) protocols which are already used, the most famous are the HTTP Live Streaming (HLS) from Apple, the Silverlight Smooth Streaming (SSS) from Microsoft, the HTTP Dynamic Streaming (HDS) from Adobe and the Dynamic Adaptive Streaming over HTTP (DASH) initiated by 3GPP within the SA4 group and developed by MPEG. These HTTP adaptive streaming existing techniques vary in the manifest file format, said manifest providing meta-data to describe the content options (bit rate, image dimensions, frame rate . . . ), the organization of the available representations of the content in segments, in the codecs supported, and in the content protection technologies.
In particular, when a client device wants to play an audio/video content, it first has to get such a manifest describing how this specific content can be obtained. This is done through HTTP by getting some ‘file’ from an URL. This manifest file lists the available representations of the content (in terms of bit rate and other properties) and, for each representation, the URLs that allow loading the content chunks for each time slice. For Video on Demand (VoD), the entire description of the A/V content is provided, while for live content (e.g. TV content), the description covers only a short period of time and needs to be reloaded periodically to discover the new items when time passes.
Depending on its capabilities and the knowledge it has from the networking environment, the client device selects one representation (e.g. based on its bit rate) and loads the first chunk(s) of content. It buffers a few chunks to be able to cope with network impediments. Then, the A/V content is played from each received chunks one after the other. At the same time, the client device measures the reception rate and may decide to select a higher or a lower bit rate. In such case, it just requests the next chunk(s) from another representation. Every HTTP streaming technique is such that it is possible for the client device to ensure a continuous playout while switching from a chunk with a given bit rate to the next chunk with another bit rate. This way when the competing traffic on the network introduces variations on the rate at which the A/V content is received, the client device is able to react and adapt by selecting chunks with a bit rate that allows maintaining the buffer filling to a secure level. Indeed, the client device tries to reach the highest possible bit rate to provide a good viewing quality to end user, while staying at a level where the rendering will not suffer from late reception of data.
While these HAS techniques have proven to work reasonably well when compared to pre-existing technologies, recent works point out that under some specific challenging circumstances (i.e. competition with another HAS client or with another TCP flow on a bottleneck), HAS implementations can suffer from severe instability issues.
In particular, it has been observed that having two HAS clients competing for bandwidth leads to unpredictable results, ultimately jeopardizing the user experience. In addition, HAS devices show incapacity to reclaim their fair share of bandwidth when competing with a greedy TCP flow (e.g. bulk traffic) because of their periodic download profile resulting in OFF periods where the bandwidth is not evaluated and then potentially underestimated. And during these OFF periods in particular, the other TCP flow can take the opportunity to grab the bandwidth.
The present invention attempts to remedy at least—but not exclusively—to the instability and bandwidth sharing issues which are characteristic of all adaptive streaming implementations in presence of other streams.